The purpose of this project is to create a computer game based on the board game Quoridor. Players of the game will be able to compete against each other on one computer or over multiple computers. In addition, AI students could theoretically be able to test AI modules by loading them into the game.

1.2) Design Goals

1.3) Lifecycle

The Quoridor Team will use the Sashimi Model below in Figure 1.3. First, understanding the basics of the game and the project are done in the “Software Concept” phase. During the “Requirements Analysis” phase of the project, one part of our team works on gathering requirements while the other part begins the “Architectural Design” phase. While parts of the team work on the Design Document (beginning the “Detailed Design” phase), other team members begin the coding phase by working on their parts of the prototype. The coding and testing will occur throughout three phases. In the first phase, we will complete all functionality required to play a complete hotseat game. In the second phase, we will add all networking functionality to be able to play on multiple computers. And finally, in the last phase, we will add AI functionality so that AI modules may be inserted.

Figure 1.3 – The Sashimi Model

2.) Proposed System Architecture

2.1) User Interface

Our proposed system will consist of three major screens. The first will help the player navigate to either a new game or a continuing game. The second screen will be a player setup screen that will allow a user to set up who will be playing each position in the game. The third screen is the playable game board where the actual live gameplay will take place. For “hotseat” gameplay (that is, all players are on the same computer), one computer will run one instance of the game. For network games there will be two to four instances of the Quoridor game running: One “host” and one to three “clients.” The host will set up the game using his program, while any clients will join the game set up by the host.

2.1.1 In-Game and Game Board Interfaces

The physical game board will be represented similarly as shown in Figure 2.1a.

Figure 2.1a – Screenshot of the game board screen (2 players)

As figure 2.1a demonstrates, there are two players: each token representing a player. Each player starts in a designated color zone on a side of the board. By default, player 1 starts on the bottom, player 2 on the top, player 3 on the right, and player 4 on the left. The target goal for each player is marked on each edge of the board with a colored zone. At the top of the screen is the game menu. A human player can access the help menu, or they can save and quit the current game. The status of each player is indicated on each side of the board. The human players can view their remaining number of walls and choose to place a wall on the board by moving the cursor over the board.

A player’s turn involves either moving a token or placing a wall. To move, a human player clicks a space adjacent to the player’s token highlighted by the computer. If a user selects to place a wall, the wall will appear in the position the user selected. After a wall placement or a token movement, the player’s turn is over, and the next player’s turn begins.

2.1.2 Game Setup Interfaces

After the title screen loads, a user will have three options to choose from: start a new game, continue a saved game, or join a game set up by a host. If the user clicks to continue a saved game, he will select a saved game from a dialog box. After a saved game is selected, the game will begin from the saved point. If the user selects to join a game, he will be prompted for connection information about the host game.

If the user selects to create a new game, a game setup screen will be shown to the user. This screen will allow the user to set up the number and location (local or remote) for each player. Each player will be either a local user, AI player, or a remote player. An example of this screen is shown in Figure 2.1b.

In this example screen, two players have been selected to play. This is actually the default setting, since Quoridor requires a minimum of two players to begin the game. This example setup assumes there are two human players at one computer, competing against each other. At the bottom, the board size has been set to 6x6 (a 36-square board), and the number of walls for each player to use has been set to 10.

Figure 2.1b – Player Setup Screenshot

2.2) Persistent Data Management

Data will be stored to a .qsv file that will contain the status of a game so that the file may be later read to continue a saved game. A game can only be saved when a player clicks “Save” from the “File” menu. This file will contain setup information of the game, information about each player, game logs, and the game state. Setup information will include the board size and the number of players. Player information includes the name and the number walls. The game state includes the position of all walls and players will be outputted to the file.

2.3) Subsystem Decomposition

Quoridor will be broken down into the subsystems shown in Figure 2.3.

Figure 2.3 – Subsystems in Quoridor

2.3.1 Interface

This subsystem will consist of all the interaction with the user. This subsystem will be responsible for collecting the information needed to start a game. Then it will begin the new or loaded game and display the game status to user. This subsystem will also allow the user to input moves or wall placements. This subsystem will interact with the Client subsystem. Invalid moves will not be allowed by the Interface. Moves will be validated by the Server subsystem. The Interface layer will receive moves made by other players (remote, AI, and local) from the Client subsystem and display these to the user. The interface is responsible for updating its own stored board state with new board states. The Interface subsystem will interact with the Client.

2.3.2 Game

The Game subsystem will store the current board state and validate moves and wall placements that are sent to it via the Server subsystem. The Game subsystem will send messages back to the Server subsystem which will indicate that the move or wall placement is valid. This subsystem will also receive startup parameters from the Server subsystem to setup a new game (ex: board size, number of players, etc.). The stored board state in Game that is connected to the server is final if the board states of the various Interfaces be conflicting. The Game subsystem will only interact with the Server or the interface subsystem.

2.3.3 Client

The Client subsystem represents a player and handles a connection to the Server and to the Interface of the local computer. The Client will connect to the Server when created. The Client serves as a gateway for moves being passed between the Server and the Interface both directions. The Client will know what player it is . Up to four Clients may exist for one game and they are not necessarily on the same computer. The Client interacts with the Server, and it interacts with the Interface of its local computer.

2.3.4 Server

The Server subsystem runs the game. When beginning a game, the Server sets the settings for the game and stores them in the Game subsystem. The Server will then listen for connections for the number of expected Clients (one Client represents one player, and may not necessarily be local). At this time, AI Modules may connect, and they are treated by the Server as if they were remote Clients. After the connections is established, the Server will send out the game settings, each player’s number, the current board state (most often blank, but may differ if a game is loaded), and the current player’s turn. If the Server receives an invalid move, it will send a message telling that the last move was invalid and that the player’s turn is skipped. The Server receives moves from the Client, validates the move by Game, and sends out the performed moves to all Clients.

2.3.5 Artificial Intelligence (AI)

The AI subsystem represents the AI Module that may plug into Quoridor. The Quoridor team will provide the header file that is required for an AI Module to connect and interact with Quoridor. The AI Module will be passed the move string. Then it is the AI’s turn, and it is expected to return a valid move. The AI Module header will only interact with the Server.

2.4) Hardware / Software Mapping

Quoridor may be played with two to four players all on the same computer. A game may also be played over a network. In the case of a network game, one instance of the Quoridor application (the host) will setup a new game while the other instances (the clients) connect to the host instance through the network. Each client will run on a separate computer. In the case where there are four players all located on separate versions of Quoridor, one player would reside on each computer to produce a total of four instances of Quoridor. An example diagram of this is shown below in Figure 2.4.

Figure 2.4 – Clients connecting to the Server

2.5) Access Control

The Quoridor program will be able to be accessed by any one who is able to obtain the executable program or access an installed version of Quoridor game on a computer. No passwords or other security features will be used to control user access.

2.6) Global Software Control

The Quoridor program is an event-driven user interface game. The system interacts with users through a Graphical User Interface. The interface displays the board to the user and allows the user to input token movements or wall placements. The whole system will be developed in Visual Basic .NET. Visual Basic is used because of the Graphical User Interface abilities available. The system must have a visually pleasing and easy-to-use interface for the user to set up and play games. AI’s will use VB.NET as their programming language.

2.7) Boundary Conditions

Initialization: The system will initialize to the setup screen before beginning a game. Changes to the board size, number of players, and player type will be made here.

Termination: The system will be terminated when the user chooses to exit the program by clicking the X at the top right side of the screen or choosing to quit the program from the menu at the top of the screen.

Failure: When a failure occurs, the user will be given a message stating that a critical failure has occurred. The application will then exit, and the user may restart the application. Examples of a failure would be a memory access violation error should the program attempt to access data outside of the array.

2.8) Testing

Our program will be tested at various times during the course of the project. We will test the Interface subsystem separately first. This test will not include any validation of legal game moves. Then, we will test the interface with the game validation included. Then, we will test the modules in groups for each phase in the project. Once module groups have been tested, the system will be tested as a whole with all subsystems. Finally, the system will be tested wholly again, but at the site of the client. A more detailed explanation of our testing plan can be found in Section 4 of the Project Plan Document.

3.) Glossary

AI (Artificial Intelligence) – refers to an algorithm that runs interactively to act as a logical sequence of actions as reflected by the actions of the human brain.

board – the square platform where tokens and walls are placed upon in Quoridor.

client – the designated players/computers that stand by as the host sets up and manages the game.

game – a session of play starting with tokens off the board and ending when any token reaches the other side of the board respective to its starting edge.

goal – colored zone on the edge of the board opposite from where a player starts. A player must reach this area to win the game.

groove – the “lines” that dissect the board, forming spaces.

host – the designated player(s)/computer that are responsible for setting up the game for all other players on different computers, referred to as “clients.”

hotseat – gameplay involving only one instance of a Quoridor game with 2 to 4 players.

jump – refers to the moving of a token past another token one unblocked space to any side of the other token.

local player – a player (human or AI) contained on a computer and not over the network.

move – a player moving from one square on the board to another square.

player – any entity interacting with the board game – can be a live person or an AI module.

remote player – a player (human or AI) contained on a computer over the network.

space – an individual square surrounded by grooves on the game board.

timer – refers to the timer that counts down the time left until the current player’s turn is over.

token – a game piece representing the player’s current position on the board.

turn – the procedure in which a player can move their token, place a wall, or pass their turn.

wall – a physical blockage which prevents players from moving across the groove where one is placed. Walls in Quoridor and in our implementation block two adjacent spaces in a line.

wall placement – placing of a wall in a valid location on the board.

4.) Contributions

Design Document Version 1.0:

Todd Astroth – Wrote Sections 1, 2.1, 3, proofreading and editing

Mark Williams – Wrote Sections 2.2-2.7, Extensive proofreading and editing

Aaron O’Banion – Extensive proofreading and editing

Chris Cobb – Extensive proofreading and editing

Matt Stowe – Created screenshots, Extensive proofreading and editing

Design Document Version 2.0:

Chris Cobb – Rewrote entire document for new design, rewrote test plan (moved to Project Plan Document)

Todd Astroth – Proofread and edited revision by Chris, updated figures/diagrams

Mark Williams – Proofread and edited revision by Chris

Aaron O’Banion – Proofread and edited revision by Chris

Design Document Version 3.0:

Todd Astroth – Updated details specific to the second semester. Created a HTML version for viewing online.

Design Document Version 4.0:

Todd Astroth – Added list of figures. Edited these sections: AI’s (2.3.5), Persistent Data Management

Chris Cobb – Helped clear up confusion on these sections: Global Software Control, Hardware/Software Mapping, AI’s (2.3.5), Persistent Data Management

Mark Williams – Updated and Edited Section 2.3 (Subsystems)

Design Presentation:

Todd Astroth

Design Poster:

Chris Cobb

Website:

Chris Cobb

Prototype:

Matt Stowe

Client Contract:

Aaron O’Banion

Chris Cobb